Since Thread.stop was removed (https://stackoverflow.com/questions/4426592/why-thread-stop-doesnt-work), the only way to re-implement such functionality is via bytecode instrumentation. This PR implements such functionality in the Scala REPL, such that we can now Ctrl-C to interrupt runaway code that doesn't check for Thread.isInterrupted() (which is what the current Thread.interrupt does) without needing to kill the entire JVM

These snippets are now interruptable where they weren't before:

scala> scala.collection.Iterator.continually(1).foreach(x => scala.Predef.identity(x))
^C
Interrupting running thread
java.lang.ThreadDeath
  at dotty.tools.repl.ReplCancel.stopCheck(ReplCancel.scala:22)
  at scala.collection.IterableOnceOps.foreach(IterableOnce.scala:619)
  at scala.collection.IterableOnceOps.foreach$(IterableOnce.scala:617)
  at scala.collection.AbstractIterator.foreach(Iterator.scala:1306)
  ... 32 elided
                                                                                                                          
scala> 
                                                                                                                          
scala> var x = 1; while(true) x += 1
^C
Interrupting running thread
java.lang.ThreadDeath
  at dotty.tools.repl.ReplCancel.stopCheck(ReplCancel.scala:22)
  ... 32 elided
                                                                                                                          
scala>           

scala> def fib(n: Int): Int = if (n <= 0) 1 else fib(n-1) + fib(n-2); fib(99)
^C
Interrupting running thread
java.lang.ThreadDeath
  at dotty.tools.repl.ReplCancel.throwIfReplStopped(ReplCancel.scala:16)
  at rs$line$2$.fib(rs$line$2)
  at rs$line$2$.fib(rs$line$2:1)
  at rs$line$2$.fib(rs$line$2:1)
...
                                                                                                                          
scala> 

The way this works is that we instrument all bytecode that gets loaded into the REPL classloader using scala.tools.asm and add checks at every backwards branch and start of each method body. These checks call a classloader-scoped ReplCancel.stopCheck method, and the Ctrl-C handler is wired up to flip a var and make the stopCheck() calls fail.

This adds some incremental performance hit to code running in the Scala REPL, but the result of no longer needing to trash your entire REPL process and session history due to a single runaway command is probably worth it. There may be other ways to instrument the code to minimize the performance hit. Some rough benchmarks:

var start = System.nanoTime(); var x = 1L; while(true) { x += 1; if (x % 100000000 == 0){ val next = System.nanoTime(); println(next - start); start = next}}

• if (boolean) throw (the current implementation): ~2ns per loop
• 1/int, which throws when int == 0: ~2ns per loop
• if (Thread.interrupted()): ~2ns per loop
• No instrumentation: ~1ns per loop

An exponential-but-technically-not-infinite recursion benchmark below shows a minor slowdown from the start-of-method-body instrumentation (~6%):

def fib(n: Int): Int = if (n <= 0) 1 else fib(n-1) + fib(n-2); val now = System.nanoTime(); fib(40); val duration = System.nanoTime() - now

• With instrumentation: 753,994,875ns
• No instrumentation: 712,178,417ns

This 50% slowdown is the worst case slowdown that instrumentation adds; anything more complex than a while(true) x += 1 loop will have a longer time taken, and the % slowdown from instrumentation would be smaller. Probably can expect a 10-20% slowdown on more typical code

This instrumentation is on by default on the assumption that most REPL work isn't performance sensitive, but I added a flag to switch it off and fall back to the prior un-instrumented behavior which would require terminating the process to stop runaway code.

One consequence of this is that REPL-loaded classes will be different from non-REPL-loaded classes, due to the bytecode instrumentation and class re-definition. So use cases embedding the REPL into an existing program to interact with it "live" would need to pass -Xrepl-disable-bytecode-instrumentation to allow classes and instances to be shared between them

The jshell REPL also allows interruption of these snippets, and likely uses a similar approach though I haven't checked